1. Field of the Invention
The invention relates generally to encryption and decryption of information and more particularly to the encryption and decryption of MIDI files and tracks distributed via a public network such as the Internet.
2. Description of the Prior Art
The following Description of the Prior Art provides an overview of the MIDI protocol, of techniques used to distribute music represented by means of the MIDI protocol, and of prior-art techniques for preventing copying of MIDI files.
The MIDI Protocol
The Musical Instrument Digital Interface (MIDI) is a standard protocol which was originally developed to permit electronic instruments such as synthesizers to communicate with each other. One common use of the protocol is permitting a musician to play more than one electronic instrument at once. The instrument that the musician is actually playing not only generates sounds, but also generates a sequence of event messages. An event message may for example be a note on message, that indicates that a note of a given pitch has started to sound or a note off message that indicates that the note has ceased sounding. Many other kinds of event messages are defined as well. Another instrument receives the event messages from the first instrument and responds by performing the actions indicated in the messages. Thus, if the message is a note on message, the other instrument will begin sounding the note, and will thus "play along with" the first instrument. For purposes of the present discussion, the event messages can be divided into two classes: the note on and note off messages and the remaining messages, which will be termed herein control messages.
The sequence of MIDI protocols to which a musical instrument directly responds is termed herein a MIDI stream. Devices which respond to a MIDI stream are termed herein MIDI devices. MIDI devices include electronic musical instruments and the sound boards of many computers. In a MIDI stream, time relationships between events are simply determined by when the events appear in the event stream. For example, if a note is to be held for a period of one second, the note on message for the note will appear in the MIDI stream one second before the note off message for the note appears in the stream. Since the MIDI device will start sounding the note in response to the note on message and stop sounding the note in response to the note off message, the note will be sounded for one second. It should be further noted at this point that the MIDI device may be assigned one or more channels. Each channel is represented by a channel number and each event message includes a channel number. A given MIDI device will respond to a given event message only if the channel number in the event message specifies one of the channels assigned to the MIDI device.
Each MIDI device has three connectors for the cables used to carry MIDI streams. One of the connectors is an output connector. The cable connected to it carries a MIDI stream of event messages that originate at the MIDI device; another of the connectors is an input connector; the connected cable carries a MIDI stream of event messages that the MIDI device will respond to if the event messages specify the channel currently assigned to the MIDI device. The third connector is a through connector; the connected cable carries the MIDI stream received in the input connector.
The connectors and associated cables can be used to configure groups of MIDI devices. FIG. 5 shows one such configuration 501. Each MIDI device 113 has the three connectors: Input 505, output 507, and through 509. Output 507(a) of MIDI device 113(a) is connected by MIDI cable 510 to input 505(b) of MIDI device 113(b), while through connector 509(b) is connected to input 505(c) of MIDI device 113(c). As a consequence of these connections, the output of MIDI device 113(a) is played on both MIDI devices 113(b) and 113(c); additionally, notes produced by players of devices 113(b) and (c) will be heard from those devices.
In the MIDI stream, the interval of time between two event messages is simply the amount of time between when the first event message appears in the stream and when the second event message appears in the stream. For this reason, a MIDI stream cannot be stored in a medium such as a file which does not preserve the intervals between event messages and also cannot be transmitted by such a medium. The problem of storing a MIDI stream was solved by a special MIDI device 113, MIDI sequencer 511. Sequencer 511 receives one or more MIDI streams 111 and makes MIDI tracks 105 out of the MIDI streams 111 and MIDI files 103 out of the MIDI tracks. The files and tracks are stored in storage devices such as standard memories and/or disk drives.
As shown in FIG. 1 of the present application, MIDI file 103 has a header 104 which contains information such as the number of tracks. The MIDI file also contains at least one track 105. A given track i in such a file is indicated hereinafter by 105(i). Each track 105(i) contains a sequence of events 106. Each event 106(j) has two parts: an event message 117 and an elapsed time descriptor 119. The elapsed time descriptor indicates the time that is to elapse between the preceding event 106(j-1) and event 106(j). As can be seen from the foregoing, a given event 106's position in file 103 may be indicated by the index of its track and its own index in the track. Event 106(i,j) is thus event j in track i.
The MIDI stream 111 is generated from MIDI file 103 by MIDI controller 107. Prior-art MIDI controller 107 does this by first writing all of the tracks 105 from file 103 into controller memory 109, as shown by arrow 108, and then reading all of the tracks simultaneously in the fashion just described, as shown by arrow 110. To accomplish the simultaneous reading, MIDI controller 107 maintains a song position time value 121 which the controller can use together with the elapsed time descriptors to determine which event messages are to be output from the tracks at a given time. As would be expected from this procedure, and as shown in FIG. 1, MIDI stream 111 generally consists of interleaved event messages 117 from the tracks 105. MIDI stream 111 may then be responded to by any MIDI device 113, which then drives loudspeaker 115 to produce the sounds specified by MIDI stream 111. The standards for both MIDI streams and MIDI files are defined in the MIDI Specification, copyright 1983 and available from the MIDI Manufacturers' Association.
An important property of both MIDI tracks and MIDI streams is that they represent commands to MIDI devices, and not the output of those devices, and are consequently much smaller than representations of the output of the devices. This property is particularly valuable where storage space is limited, for instance in low-cost electronic devices, or where a low-bandwidth medium such as the Internet is being used to transmit the representation.
Distributing MIDI Files on the Internet
The advent of the personal computer opened whole new realms of applications for MIDI. First, many computers had sound boards that could interpret MIDI streams and were therefore themselves MIDI devices. Second, MIDI's small size and ability to represent actions that happen in real time made it attractive for any such application. For example, makers of game software used MIDI to provide program-controlled sensory feedback to a joystick. Finally, there was the wild growth of the Internet. The Internet's bandwidth problems made MIDI particularly attractive as a way of distributing music for MIDI devices over the Internet. FIG. 1 shows a prior-art technique for distributing music over the Internet An important limitation of the Internet is that it is not a real-time medium. This problem was overcome in the prior art by distributing music for MIDI devices over the Internet as MIDI files 105 using the techniques shown in FIG. 1. First, a MIDI file 103 was made from the MIDI stream 111, then the MIDI file was distributed over the Internet, and the arrangement shown at 101 of FIG. 1 was used to play the file on a MIDI device 113. The parent and the grandparent of the present patent application both concerned improved techniques for overcoming the non-real-time characteristics of the Internet and thereby making it possible to begin hearing a MIDI file without delay and to hear MIDI music as it was produced.
Protecting MIDI Tracks and Files: FIG. 12
The present patent application deals with the problem of protecting MIDI tracks and files from unauthorized copying. Copying is generally a more severe problem in the digital realm than in the analog realm because a copy of a digital representation is as good for all purposes as the original digital representation. In the case of MIDI tracks and files, copying is made even more attractive by the smallness of the MIDI representation and by the fact that it can be played on any kind of MIDI device.
In the prior art, MIDI files and tracks have been protected against copying by using the encryption and decryption techniques generally available for data. FIG. 12 shows a system 1201 in which such techniques are applied to a MIDI file 103 which is being sent by a network 1211 from a source 1203 to a destination 1213. MIDI file 103 is provided to encrypter 1207, which uses one of many known techniques to produce an encrypted version of MIDI file 1209 which has been encrypted using an encryption key 1208. Once encrypted, the file may only be decrypted by someone who has a decryption key for the file.
Encrypted file 1209 is then sent via network 1211 to destination 1209, where it is decrypted by decrypter 1217 using the decryption key 1218 appropriate to the encryption made by encrypter 1207. Decrypted MIDI file 1219 is identical to original MIDI file 103 and can be read by a file to stream translator 1221 to produce a MIDI stream 111 in the fashion described above. MIDI stream 111 is then sent to MIDI device 113, which produces analog signals 1227 that then go to loud speaker 115. For an overview of the large variety of encryption techniques which may be employed in system 1201, see Bruce Schneier, Applied Cryptography, Protocols, Algorithms, and Source Code in C, John Wiley and Sons, New York, 1994.
From the point of view of preventing copying of MIDI tracks and files, the arrangement of FIG. 12 has a number of problems. What the publisher of the MIDI track or file wishes the user to get in unencrypted form is only the sound produced when the MIDI device plays the MIDI stream. Even giving the user access to MIDI stream 111 is unacceptable, since anyone who has a MIDI sequencer 511 can produce a MIDI file 103 from the MIDI stream 111, and MIDI sequencers 511 can easily be implemented in software that will run on a standard personal computer (PC).
In system 1201, the user has access to decrypted MIDI at many points. Most obviously, system 1201 produces decrypted MIDI file 1219, which is accessible to the user of system 1201 and is equivalent for all purposes to original MIDI file 103. The user further has access to events 1220 as they are read from decrypted MIDI file 1219 to file to stream translator 1221, and can simply read the events into his own MIDI file. Finally, the user has access to MIDI stream 111, and can output stream 111 to a sequencer 511 to make his or her own MIDI file 103. One feature of modern computer systems which makes access to events 1220 and MIDI stream 111 particularly easy is that file to stream translator 1221 and MIDI device 113 are often implemented as dynamically-linked software libraries (DLLs). When a program executing in a personal computer uses programs in a dynamically-linked library, the DLL is linked to the program that uses it as the latter program begins executing. It is consequently easy for the user to substitute his own DLL for either the file to stream translator or the MIDI device 113 for the ones intended to be used to play the MIDI file, and instead of playing the MIDI file, the user can simply output the events 1220 to a file of his own or output MIDI stream 111 to a sequencer 511.
There are a number of requirements beyond security which must be satisfied by a commercially-viable encryption system for MIDI tracks and streams. First, a single source will be typically transmitting a file or track to many destinations. Second, many granularities of encryption must be possible. On the side of the publisher, it must be possible to encrypt entities ranging in size from the equivalent of a multi-CD album through a live concert down to an individual song; on the side of the recipient, it must be possible to implement decryption on a per-site, per-machine, per-code copy, or per-instance of execution basis. Finally, any encryption scheme must be cheap, but it also must be effective enough. In the context of MIDI publishing, effective enough means that it need not provide absolute security, or even security against a professional hacker, but simply be secure against the ordinary user.
It is an object of the present invention to overcome the problems of prior-art encryption for MIDI files and provide commercially-viable techniques for encrypting and decrypting MIDI tracks and files.